What is a Requirement Really?
What is a Requirement really?
Each new project starts like the new season of summer and sun. Project expectations are high, everyone is excited. Success is evident. But there is a question that needs to be addressed. The question is so simple really, but is actually one of the leading causes of project failure.
“How do we define what a business requirement is?”
Let’s first dive into the differences between Business Requirements and User Stories.
Business Requirement Definition:
Definition: A business functional requirement is a statement that tells us what the business wants. Functional requirements provide the basis for the system’s design and testing, while use cases provide the basis for the system’s validation and verification.
Rule: There should only be one primary requirement because it facilitates the Agile process which works on Epics. An Epic is a large, complex piece of work that’s too big to be completed in a single sprint or iteration or a large body of work that is broken down into smaller user stories or tasks. Invoicing would be an Epic that would move through multiple Sprints (see example below).
Functional Business Requirements and UAT (User Acceptance Testing) go hand in hand. UAT is done by the business and this is where the business can see if the requirement they provided was accomplished per their expectations. Functional requirements provide the basis for the system’s design and testing, while Use Cases (covered below) provide the basis for the system’s validation and verification. User Acceptance Testing is what business functionality is about.
Requirement Example 1: The Business Users need to have invoicing brought through the Work Order process (not paper as it is currently done) so that… Field Tech workers can do immediate actions on site like sign off, billing, invoicing and rescheduling in a single click without bringing paper work back to the office and having payments pushed 2 to 3 weeks out which impacts the monthly financial closure process of the business.
Example 2: Omni channels for claims…coming
Looking at the business requirement examples above, we can see that there are many actions needed to finish each of these individual processes. This is where the User Story comes in.
Once the Business Requirement is completed, the SA (Solutions Architect) makes it consumable for the developers by building a Technical Specification or ‘Tech Spec’ document. This is an intermediate document that drives the User Stories and is not covered in detail for this article but for now in short a Tech Spec is a response to the business requirement such as: I need X objects, X fields, flows and opportunity processes.
The next step of this process is building the User Stories which the BA (Business Analyst) will typically create as the SA will focus on the actual technical solutions while providing design and solution overview for BA guidance.
User Story Definition:
Definition: A User Story is a description of a software feature or requirement written from the perspective of the end user. User stories are often written in a narrative format and help development teams understand the user’s needs and motivations. User stories are a key part of agile software development and are used to help development teams understand what users want and need.
Rule: Multiple User Stories (1:M) support the individual business requirement. These multiple User Stories make up the User Story Unit or package.
User story and system integration testing go hand in hand. Each US comes with success criteria which the (QA) Quality Assurance Team signs off by using all integration systems to see that the Developers have done the work to ensure all areas of the US were accomplished successfully.
The best practices of the User Story development process have already been provided via the internal CoE (Center of Excellence) team discussed below.
Requirement Example: In the invoicing business requirement above, each role and/or experience can be a separate User Story. Just for starters there is the Account Rep for prepping Account, Finance for billing, Field Service Technician for onsite work, System Admin for scheduling appointments (automation), and more. That is all out of one bus requirement and each of these experiences can be a separate User Story. All of these go into a single function that was provided by the business side.
The SA and Developers review the details held in the User Stories (created by the BA) for technical implementation options and solution designs which may include: Data modeling, MD relationships, summary fields, objects (structure) and flows or code (actions) and impacts to governance, reporting, etc. The ‘structure’ supports the ‘actions’ which take into account the data mindset to design for sustainable and streamlined capabilities.
Now, let’s discuss what some of the challenges are to building a better business requirement because they often don’t define roles or bus criteria, values are not defined well and often there are no metrics to measure whether success has been achieved.
For that matter, how do we know the requirement is not just done, but done successfully meaning teams can build it and it can be measured?
How do we build a standard process to create a requirement that can then be written as a User Story for the offshore teams to execute on? It’s not just a one and done here, the technical teams (SA, BA, TA, etc) need to consume and may need to refine the requirement to meet completion status and then write the detailed documents mentioned for development execution. This takes time.
What happens when the requirement is not complete? What is the process to get it completed? Does it get tagged and go back to the Product Owner for additional work with explanations? What is the SLA for the timelines of the responses? What does the ‘status’ look like so it doesn’t get lost, misplaced or pushed along anyway. Keep in mind, there are X points due per week for this project. How are you going to keep this pace and keep the developers – all of them busy without losing momentum through the sprints?
This is what we are going to discuss in this article.
In short: Maintaining Momentum & Control through the project by defining what a requirement is.
Defining a Requirement:
There are 3 parts of a requirement. If someone tells you there are more than 3 they are complicating the process – just keep it simple.
The 3 parts are:
Who? Who is it for? Which defined division, role, etc?
What? What is it that you are trying to accomplish?
Why? Why are you doing this? Why is this important to you, to your client, to the business, whomever. What is the VALUE? The WHY is usually followed by ‘so that…’ This is where you get into the depth of the requirement. Is this a nice to have? Is this a MUST have? Who asked for this to be done, business or tech? Is it tied to revenue? What are the value points? Very important, not so important are too vague? Are there dependencies that provides support for this requirement? You may have additional requirements that need to be accomplished first? It would also be nice to have some metrics to define success of the requirement but I’ll stop there…
You may have 3 simple questions to define a requirement but you have many important concerns to address to be sure you can write up a User Story from the requirement for a development team to execute successfully. What if you have to address 200+ requirements. You can’t keep asking the same questions to your teams or client as the requirements come in. You can’t give them all equal amounts of attention and not all requirements are created equal. It would be overwhelming and frustrate everyone on the teams impacting the trust. You must set up your processes and standards but where do you start.
If you’ve guessed already that I’ve been through this many times you would be right. It happens on every project at different levels. I’ve had scenarios where requirements are being created by the Product Owners, Business Owners, 3rd party companies that are not technical, the Clients development and business teams, our own teams via the discovery phase or a combination. Sometimes in the discovery phase we are able to work on the requirements provided by the client but this is not the norm. That’s if we get lucky.
Everyone will have their own interpretation of done but that doesn’t matter to you because you have already set up your internal CoE (Center of Excellence) team to outline what a requirement and a tech spec looks like. Your team has also agreed and outlined visually what the process looks like as you move from: creation > refine > design(solution) > build > test. You will also plan together for disruptions like people leaving without notice. Life happens so you need to be prepared as a team with contingency plans and clear actions.
Special Note to Assumptions: If there is an ‘assumption’ consider this an action of ‘stuckness’ that should be attacked like a virus. Be urgent and immediate in your daily standups to address any and all assumptions as they are ‘death’ to many projects. Actual overheard conversation: “I assumed you were cleaning the data?” “No, our teams don’t have the skill set for this, there are X different systems of data?!”, “But that will take 3 weeks?” Project stalled – Client TRUST dead.
Our Scenario:
Lets start with an actual scenario: You have 100 points due per week. 4 producers on the tech team and 15 developers. There are 5 total sprints lasting 10 weeks so one sprint takes 2 weeks. The challenges are as follows:
Keep the developers busy and on task to accomplish the weekly goal of delivering 100 points.
To do this you need to keep up the pace of delivering X amount of User Stories to the teams in a completed format that they can execute on.
Maintain 3-4 hours with the offshore dev team per day to review and refine the User Stories/Requirements so that they are understood and signed off on – not delayed and you miss your weekly mark.
As mentioned this is a real scenario. If you are a techie you know that you need to use ‘Velocity’ to manage and measure your momentum and control.
Velocity Definition: In Agile, velocity is a metric that measures how much work an agile team can complete in a specific time frame. It’s used to help teams plan and create timelines, and to identify inefficiencies in the development process. Its calculated by dividing the total number of user story points or backlog items completed by the total number of days in the sprints. Velocity can be measured in units of work, such as user stories, engineer hours, or story points.
Your Scrum, Engagement or Program Manager can lead and own this process as its the primary measure of success and needs to be addressed daily to keep the teams’ momentum and timing on target.
Let’s go back to our scenario. Let’s say that one of the 4 User Story producers decides they don’t have time to do the work and need to focus on why they were hired – let’s say a Technical Architect (actual scenario) will only do a smaller amount of the work load. This should not have happened because you already spoke with the Engagement and Account Manager at the start of the project and the expectations were addressed but things changed and you are now loosing control. You now have 3 producers and one consumer in your team. You now have 1/4 or .25 of your development team sitting on the bench. Management asks why they are not working on the builds of the User Stories and that you will fall behind. You explain the situation but hiring a new person will take time. 100 points are now 80 points for delivery multiplied by 10 weeks. You are already in the RED. What do you do?
At this stage you are in reactive mode and you need to get control back immediately. Your goal is to keep the momentum of the team and project moving forward.
First, share this information as an URGENT status with your Managers (*Account team) with a phone call so that they can immediately begin to align the actions and allocate people and finances needed to keep the clients trust and expectations. Don’t hide it hoping it will resolve itself with your guidance. Be transparent and make sure to have it in writing in an email sent specifically to your managers and CC only your Engagement and Sr. people on the team. Then make sure you schedule an immediate meeting to speak with them and the selected people from your team. An email is only to protect the project and your teams, its not the channel to have a conversation of this urgency. And during this time – Keep the calm and clarity of the project intact. Remember that you are the guru and guiding light of all you serve.
Actions to take are as follows:
Set up a time on the calendar for daily checkins (sometimes twice a day) with your manager for updates, actions and status.
*Make a list of immediate actions your team can take to get things back in control. Here are some examples:
Create a War Room: A war room is where everyone can see one another and what they are working on at a defined time in a transparent and highly visible state. There is no messing around – this is URGENT so everyone needs to be on deck, accountable and focused. Begin by getting some of the developers to pitch in from the client side and/or your offshore teams. That means that hours may need to be moved around to adjust for 1:1 time with the developers as they may be on different time zones. Explain that this is temporary but needs to be done so that you can get this bump in the road far away from you.
Push back on the Product Owners who are creating the requirements and address higher standards for the details produced. Adjust the template with the CoE team and push forward with the expectations and adjusted processes. They may have to work more as a team and it is important to have a technician dedicating some time to assist. Again, this is temporary but is actually a great idea to keep as a standard if you are having issues in the requirement translation.
You will also need to hire more people immediately to step in even if for a temporary time frame but you need bodies to throw at this and they have to have some skill sets to meet the job requirement. As mentioned above, your Managers should help with this action and it should be a team effort. Everyone needs to be reaching out and recruiting. You are all in the same boat and if its rocking – everyone is going to get sick.
I know what you are thinking – I just wanted to know what a requirement was. Well, this is real life and some of your gaps are found in your Requirements, User Stories and Tech Specs. Hence, the detailed review of what happens on a project. I have quite a few scenarios but if you do what I spoke about in this article, you should have a better chance to start and maintain the control, momentum and velocity of a project.
There are many things out of our control – but we can still put a rope around them – call them out and wrestle them in with the right help.
Now put on a good show for the Gods.
Example of a High Level Project Template (to begin project standards for teams):
Individual requirements will require a different template but this is a great starter to set the standards.
Client Name
Case Study Title
About Company
Program Objective
Business Content (Requirement)
Technical Complexity
Solution Highlights
Solution
Benefits
How it is now (current state/challenges)
Lesson Learned